The idea for #19387 is that we might be able to push down trivial expressions here, thus avoiding the need for any physical optimizer changes/rules.

Maybe we can drop this since filters are effectively pushed into TableScan now?

I think this would be a problem in scenarios like UPDATE target FROM source ... where the input plan contains TableScan nodes for both target and source. This function will extract filters from both tables and attempt to apply them to the target table (after stripping qualifiers).

Hmm interesting. Is the problem the stripping of qualifiers? It seems to me that the current implementation is generally fragile: we should be taking into account the join aspect and only collect from subtrees of the join. In particular:

> explain format indent UPDATE "trg" SET col = 1 FROM src WHERE trg.id = src.id AND src.type = 'active' AND trg.id > 100;
+---------------+-----------------------------------------------------------------------+
| plan_type     | plan                                                                  |
+---------------+-----------------------------------------------------------------------+
| logical_plan  | Dml: op=[Update] table=[trg]                                          |
|               |   Projection: trg.id AS id, Utf8View("1") AS col                      |
|               |     Inner Join: trg.id = src.id                                       |
|               |       Filter: trg.id > Int32(100)                                     |
|               |         TableScan: trg projection=[id]                                |
|               |       Projection: src.id                                              |
|               |         Filter: src.type = Utf8View("active") AND src.id > Int32(100) |
|               |           TableScan: src projection=[id, type]                        |

It seems to me that we should do something like:

1. Find the table scan corresponding to the table being updated.
2. Walk up the tree until we hit a join / subquery (?) / other blocker.
3. Collect all filters in that subtree (ideally once this PR is across the line they've all been pushed into the TableScan so that becomes trivial)

I don't know how the DML stuff is supposed to handle more complex cases involving EXISTS, etc.